Tips to build Reusable Objects in PeopleSoft

Introduction

From my first day in IT (as a learner on PeopleSoft) in 2009 to the present day, I have looked for an opportunity to learn or achieve something new every day. It might be a simple concept, a feature, an application functionality or the task that was assigned. Over time, while working for multiple clients and on various business cases, one thing became clear: every requirement or business case needs something that was already developed or available. It would be harder to find someone who doesn't agree with this fact. I'll explain it with a simple example: let's say you need to build a setup page (this can be anything), which will definitely need audit information like who created it, who updated it, and when it actually happened, etc. Some of us might have cared less about those areas as they may not be the core of the business case you are working on or a required feature, but I would say it is still a part of the development cycle.

Brief

These reusable logic/components can be as simple as creating an audit sub-record with the necessary update logic, or as complex as building an entire framework that would be beneficial throughout PeopleSoft applications or even beyond. It is very important to have these kinds of components in the long run, because the more you work on individual requirements (be it development or implementation), the more maintenance will become an added effort for either the supporting partner or the customer themselves.

Assume you have created a component with no row-level security since the requirement was for only one or two admin users to access it. A few years later, the organization restructures and the team size increases to 10. Now the customer wants to distribute access as reviewers and controllers; some should see a set of data but not all. A pretty expected change, right? Now imagine you get similar requirements for 10 more components because they are all admin pages. You would need to spend at least a week making these changes and several more days on integrated testing. How would you feel if 50-70% of client requirements were like this? Well, that's exactly the case for 50% of the customers I have worked with.

On many occasions, these kinds of visionary inclusions may not come as a formal business requirement. As a professional, it is our responsibility to consider these extreme cases and build in the capacity to accommodate future requirements.

Way of thinking changes everything

You might think, "How am I supposed to know the future of the customer's business scenarios and requirements?" Well, you can't. You just have to assume or make an expert guess about the requirement. Following are some questions you should ask yourself before finalizing your design or starting your development:

• What is the load of this functionality (e.g., concurrent user count, number of rows added/updated per day)?
• Where does the data go or come from? Is it just for recording, reporting, or is it a source for something else?
• Can this be considered an end product, part of a product, or just a utility?
• What security checks and audit concerns might be involved?
• What data is it dealing with?
• More importantly, what can you do to reduce maintenance?

These questions will give you insights into the business requirement and how well you can prepare to create reusable components and build maintenance-free business processes.

Here are some use-cases

Here, I would like to share my opinion on including reusable objects to make support work easier and to give a better product to the customer.

• Always try to use sub-records (e.g., for addresses, attachments, audit fields).
• Add dynamic code instead of static variable/field names (e.g., GetRecord(), GetField()).
• Use Application Packages more often, even in your event-level code (e.g., SavePreChange, FieldEdit).
• Create generic methods that can be used organization-wide.
• Create Header/Footer sub-pages (each customer wants them on their ESS/MSS pages). Alternatively, you could use pop-up pages when possible.
• Add sufficient documentation/comments to objects so they can be extended instead of redeveloped.
• Use menu-level search record overrides to save a lot of time in developing MSS and Admin components.
• Avoid cloning code; instead, use functions/methods/application classes.
• Create CSS specific to customer needs and reuse it. Use field-specific styles if needed.
• Use delivered configurations as much as possible (i.e., Enterprise Components and Life Cycle Components).
• Use SQL Objects/Dynamic Views for data retrieval; better yet, use Record Objects with Filter/Select methods.
• Use scoped variables according to the requirement (e.g., getting the employee job code by SQLExec on every event is unnecessary).

Some samples

1. Simple method to check if a given row is present in the audit table.

method CheckNIDLog
/+ &rPERS_NID as Row +/
/+ Returns Boolean +/

Local Record &recSV_PERS_NID;
&recSV_PERS_NID = CreateRecord(Record.BD_SV_PERS_NID);
&recSV_PERS_NID.EMPLID.Value = &rPERS_NID.PERS_NID.EMPLID.Value;
&recSV_PERS_NID.COUNTRY.Value = &rPERS_NID.PERS_NID.COUNTRY.Value;
&recSV_PERS_NID.NATIONAL_ID_TYPE.Value = &rPERS_NID.PERS_NID.NATIONAL_ID_TYPE.Value;

Local boolean &bRslt = &recSV_PERS_NID.SelectByKey();
If &bRslt Then
If (&recSV_PERS_NID.NATIONAL_ID.Value <> &rPERS_NID.PERS_NID.NATIONAL_ID.Value Or &recSV_PERS_NID.VERIF_STATUS.Value = "Fal" Or
%This.bDOBChanged) Then
Return True;
End-If;
End-If;

Return False;
end-method;



2. A DictionaryClass as an utility.

Recently, I created a Dictionary Class to store and manage a list of values. When a traditional Array class doesn't fit, this can be extended to have a key-value pair. I'm not saying this would directly help you, but it gives you an idea of how generic objects can be built.

DictionaryClass Code Sample - GitHub

I will try to add new objects and references here for everyone's reference going forward.

Conclusion

Overall, by reducing the time you spend working on known things and focusing on new things, you can improve both the speed of your solutioning and the quality of the product you deliver. By spending 2-4 hours on something that could possibly reduce 5% of the development effort in the future, I suggest you do it. In the long run, that 5% will add up and provide huge benefits to your project SDLC.

Initially, learning the different ways explained earlier might take some time, but ultimately that effort will give you confidence and lead to appreciation for your deliveries.

 
Use the comment section to share what similar experience you had in your career.

As always Happy Learning 😊